查看原文
其他

1500字节为何成为互联网MTU标准?

Dmitry Nosachev 高可用架构 2020-11-06


以太网无处不在,几乎所有硬件厂商都有涉及,所有以太网链路都有一个共同的参数:MTU。


$ ip l1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:002: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff


MTU(最大传输单元)规定单个网络数据包最大长度。一般来说,在局域网中的设备通讯时,MTU 大约为 1500 字节;实际上互联网也普遍以 1500 字节运行。但是这并不意味着链路层技术无法传输更大的数据包。


例如,802.11 网络也就是大众所了解的 WiFi)MTU 为 2304 字节;如果你使用光纤则 MTU 约为 4352 字节。以太网本身具有“巨型帧”的概念,其中 MTU 可以设置为 9000 字节(如果网卡,交换机和路由器支持)。


但是这些在互联网上都意义不大,因为 Internet 主干网目前主要由以太网链接组成,因此数据包实际最大长度现在都是非正式地设置为 1500 字节,以避免数据包在传输链路上被分片


从表面上看,1500 是一个奇怪的数字,计算机领域碰到的很多数字都基于数学常数,例如使用 2 的幂。但 1500 显然不属于前者。


那么 1500 是从哪里来的,为什么我们仍在使用它呢?


魔术数字


以太网问世第一个重大突破是以 10BASE-2(细)和 10BASE-5(缆网)的形式出现,最后的数字是说单个网段可以跨越几个百米。


由于当时有许多竞争协议,并且存在硬件限制,早期设计者在一封电子邮件 (1) 中指出数据包缓冲存储器的需求一定程度决定了 1500 这个数字。(感谢推友 @yeled 提供资料)


回顾一下,大一点 MTU 可能会更好,但是在早期会增加网卡成本,并进而影响以太网的广泛采用。


1980年发表的论文“以太网:本地计算机网络的分布式数据包交换 (2) ”,是对网络大数据包效率成本分析的早期记录。这对当时的以太网设计尤其重要,因为当时以太网在所有系统之间共享同一同轴电缆,或者使用以太网集线器,后者一次只能允许一个数据包在以太网网段的所有成员之间传输。


因此必须选择一个合适的数值,这样在共享网络(有时很忙)上的传输等待时间不会太久,而且数据包头的开销也不会太大。(请参阅前面提到的论文第15-16页)


因此程师最终择了 1500 字节(约 12000 bit)作为最佳“安全”值。


这些年来,各种传输系统出现与消亡,但是它们的 MTU 值仍然使用以太网的 1500 字节。大于 MTU 可能会导致 IP 碎片,或者需要进行路径 MTU 检测。两者都有各自的问题。(为了保险)有时大型操作系统甚至会将默认 MTU 设到更低的水平。


效率的因素


现在我们知道互联网 MTU 1500 主要是由于旧的时延问题和硬件限制,接下来我们分析这个数值对互联网的效率影响到底有多大。



如果我们查看来自骨干 Internet 流量交换点(AMS-IX)的数据,发现 20% 的数据包通过该交换设备时最大长度


我们还可以分析局域网的总流量:



如果将这两个图结合,你将得到如下所示的内容。这是不同大小数据包有多少流量的估计:



果我太网包头所占用的流量,则会得到相同的图表,但比例不同:



这表明在最大的数据包上,仅是数据包头就消耗了大量带宽。由于峰值流量显示开销大约 246G Bit/s 的开销,因此我们可以假设,如果有机全部采用了巨型帧,开销仅约为 41G Bit/s


但是我认为,我们已经航行在更广阔的互联网上。尽管某些互联网运营商使用 9000 MTU 进行运营,但绝大多数运营商不这样做,历史一次又一次地表明,想要改变互联网的集体想法极其困难


如果你对 1500 字节的 MTU 以太网历史有更多了解,请通过电子邮件联系作者 ethernet1500@benjojo.co.uk。难过的是,网络上与此相关的手册,邮件列表帖子等内容正在迅速消失。


文中链接:


  1. https://blog.benjojo.co.uk/asset/1hhfq2UR8

  2. https://blog.benjojo.co.uk/asset/4Up5QvCjA


原文链接:

https://blog.benjojo.co.uk/post/why-is-ethernet-mtu-1500


参考阅读:


本文作者 Dmitry Nosachev,由高可用架构翻译。技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。


高可用架构

改变互联网的构建方式


长按二维码 关注「高可用架构」公众号

Modified on

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存